Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

Huh, somehow my rebase lost that part! I def did edit that, will push...

Rebased to fix minor conflicts, and added minor fixes in separate commit.

OK, I am now running this on my two main test nodes:

mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605
testnet: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769

It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today.

With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet.

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate.

This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game.

Adding a CSV value makes the recovery case less self contained.

What does that mean ?

Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ?

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key
Having you peer include in its commit tx an output that sends directly to your wallet

Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper.

My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address.

There are already wallets that only derive witness v0 outputs, e.g. Wasabi and Electrum.

edit; and there is no need for a transition period between v0 and v1, as in theory anyone who can pay to v0 can also do so to v1.

@Roasbeef I don't see why adding a delay here prevents you from recovering your funds ? My point is that not having such a delay was bad before and we're making it worse.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

@SomberNight well we'll have eltoo by then won't we :) but it may not be soon...

I don't see why adding a delay here prevents you from recovering your funds ?

It doesn't prevent it, it makes it less self contained: recovery logic now needs additional data (to reconstruct the script).

My point is that not having such a delay was bad before and we're making it worse.

With my response being that the real incentive issue here is the initiator always paying the fees whenever a channel closes.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

This is the very problem that's being fixed with this change.

@Roasbeef Meeting nodes say this is pending your ack to merge? Ping!

@rustyrussell needs a rebase! I'll make another PR to add that note re compatibility with detecting proper data loss from state zero.

Actually, the current text looks fine, scratch my last comment, doing one final pass over everything.

needs rebase!!

Trivial rebase, and collapsed into a single commit.

This appears to allow to self-select an address from the Lightning Client's wallet only. Is anything planned that would require channels to close to an arbitrary user-selected addresses in the force-close scenario?

I have a question for this change: With this change is it possible to use low fees on the commitment transaction and in the case of a force close use CPFP to get the transaction through? I really hope this is possible some day since if the fee market gets serious the high fees for commitment transactions serving as an upper bound will be a big problem in my opinion. Using CPFP would enable a much more dynamic fee system and every participant could decide for themselves how fast they need the assets / how much they want to pay for fees.